Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9701/000059_owner-urn-ietf _Fri Jan 31 16:20:27 1997.msg

Internet Message Format | 1997-02-19 | 5KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA13301 for urn-ietf-out; Fri, 31 Jan 1997 16:20:27 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA13296 for <[e-mail]>; Fri, 31 Jan 1997 16:20:24 -0500
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA00895  (mail destined for [e-mail]); Fri, 31 Jan 97 16:20:20 -0500
Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id OAA08668; Fri, 31 Jan 1997 14:20:11 -0700 (MST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 31 Jan 1997 14:19:50 -0700
To: Daniel LaLiberte <[e-mail]>
From: "Ron Daniel Jr." <[e-mail]>
Subject: Re: [URN] Re: Relative URLs and URNs
Cc: "URL mailing list" <[e-mail]>, <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
Reply-To: "Ron Daniel Jr." <[e-mail]>
Errors-To: [e-mail]

Thus spoke Daniel LaLiberte:
>Ron Daniel, Jr. writes:
> > The point I was trying to make is that the presence of the relative
> > URLs is not helping us as we make the transition to URNs.
>
>Relative URLs (which are relative URIs intended to be interpreted
>relative to an absolute URL) would not interfere with a transition
>to URNs if you keep the same absolute URL base.

Not always true. If our resolver offers the N2R service, its nice to
use it because bookmarks will be to the URN, not to a URL. Similarly,
the Location: text field in netscape will display the URN. However,
that means that relative URIs will be relative to the URN, not the
URL of the instance we fetch. Since the hierarchies are not the same,
it breaks.


> > For example, the document at
> >   http://www.acl.lanl.gov/URN/index.html
> > might get a FPI of
> >   -//LANL ACL//199703014039//EN
> > which results in the URN
> >   urn:fpi:-%2F%2FLANL%20ACL%2F%2F199703014039%2F%2FEN
>
>Is it true that the fpi URNs are non-hierarchical, or if they have
>hierarchical structure, you don't want to expose it?  (I'd recommend
>that the syntax of fpi URNs expose the structure and avoid reserved
>chars, something like urn:fpi:/LANL/ACL/1997/03/01/4039/EN)

FPIs do have a hierarchical structure, and I have no strong feelings
either way about exposing it. What I do care about is a reasonable
approach to granfathering old namespaces. About the only objective
criteria I know of for determining if a mapping from a legacy name
to a URN is reasonable is to see if it is invertible. I can't recover
the original FPI from your sample encoding of it because your '/'
character could map to space, //, or nothing at all (where you put
them into 1997/03/01/4039). (They could also map to :: in some FPIs).
Being able to map to the original identifier is important since it allows
us to add a URN resolution gateway on top of existing databases.


Putting that problem aside, lets assume that I can use
  urn:fpi:/LANL/ACL/1997/03/01/4039/EN
to refer to the document currently known as
  http://www.acl.lanl.gov/URN/index.html
which has a relative reference to
  HREF="software.html"
Since we are using N2R in order to get bookmarks to use the persistent name
for a resource, Netscape would try to fetch new URNs that look like
   urn:fpi:/LANL/ACL/1997/03/01/4039/software.html

This is the crucial problem with relative URNs. There are LOTs of
different hierarchies into which a document can reasonably be placed.
Relative URNs will persist across namespace transitions if we keep
the same hierarchy. If we want to change the hierarchy, the relative
references will no longer work. The scary thing about relative URNs
is that if you access the document using someone else's name for it,
your relative links will break (unless you have used something like
the BASE tag, but then we are back to editing the documents to move
to a new namespace).


>Relative URNs *are* likely to save one a significant amount of work *if*
>you use a name space that is hierarchical and that supports relative
>URNs.

... *and* if your next namespace uses the same hierarchy as the earlier
namespace. (In which case, why are you switching?)


Ron Daniel Jr.              voice:[phone]
Advanced Computing Lab        fax:[phone]
MS B287                     email:[e-mail]
Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545